This invention relates to the field of data processing systems, and in particular to a global data binding system that facilitates data binding between a data consumer and a data source in a manner that can be independent of any container that may be associated with the data consumer.
Data binding is the technique of creating a logical association or link between a data consumer and a data source. A data consumer is typically implemented in a container and uses data in a manner that can include, but is not limited to, displaying data on a display screen by way of a display mechanism, manipulating data, or associating data with properties of non-visual objects. A container is a type of component that contains one or more other components within a component family hierarchy, and can include but is not limited to a viewer or other visual object on a display screen such as a button, data entry field or form, and/or a list box. The display mechanism is an object referred to as a bound control that has properties that include data presently being displayed, background color, title, and other visible properties that can each be linked to a different data source. For example, the title of a bound control may be linked to a first data source, and the data displayed within the bound control may be linked to a second data source. A bound control is responsible for displaying properties to a user so that the user may view or modify the properties of the bound control.
A data source typically includes a data store, a data source control, and a cursor. A data store is typically a non-volatile storage device that on which data persistently resides often in a tabular row and column form called records and fields. A data source control is an object that is the interface between the data consumer and the data store that controls the display and implementation of data manipulation options. A cursor is an object that maintains a subset of the data store called a result set of a query, and maintains a present data item location indicator called a currency. The cursor supports operations that can be performed on a result set from the data store that include, but are not limited to, retrieving a record from the result set at a present location called the currency, modifying a record at the currency location, and moving the currency to refer to a desired record of a result set.
FIG. 2 illustrates an example of an existing data binding model 200 in block diagram form. Note that the context of the basic computing system components identified with 1xx series reference numbers are disclosed in further detail with the text accompanying FIG. 1 found in the Detailed Description of the Invention section of this document.
Display screen or monitor 191 is illustrated as displaying two display areas 210 and 220 that are also referred to as containers. The visual components 211-213 within display area 210 are controlled by container application 230 of the application programs 135 in system memory 130. The visual components in the present example include, but are not limited to, user-visible bound controls 211 and 212, and a user-visible data source control 213. The binding components 231-234 of container application 230 can include, but are not limited to, a binding control 231 that controls user-visible bound control 211, a binding control 232 that controls user-visible bound control 212, a data source control 233 that controls user-visible data source control 213, and a cursor control 234. Similarly, the visual components 221-222 within display area 220 are controlled by container application 240 of the application programs 135 in system memory 130. The visual components in the present example include, but are not limited to, user-visible bound control 221, and user-visible data source control 222. The binding components 241-243 of container application 240 include, but are not limited to, a binding control 241 that controls user-visible bound control 221, a data source control 242 that controls user-visible data source control 222, and a cursor control 243. Both container applications 230 and 240 are operatively connected to the data 250 in the non-volatile secondary data store 141. The binding components within the respective container applications 230 and 240 are internal binding arbiters between display areas 210 and 220 as data consumers, and data 250 in data store 141 as the data source.
The operational aspects of data binding can be appreciated by considering a situation where a data consumer that has a local copy of data from the data store of a data source, and the data consumer has the data displayed on a display screen under the control of a data source control. Because the data consumer and the data source are logically linked, modifications to the data consumer""s copy of the data result in an update of the data of the data source. Similarly, modifications to the data source""s copy of the data result in an update of the data of the data consumer. However, existing data binding configurations and their operational techniques to facilitate data binding such as that illustrated in the FIG. 2 example, are undesirable for several reasons.
One reason existing data binding techniques are undesirable is because existing data binding models are unique to each container application. This data binding uniqueness requires a programmer to duplicate a relatively standard service from one container application to the next and to customize the container application to accommodate a specific data access protocol and interface set. Generating a customized data binding implementation for each application is inefficient and results in programming language code that is dedicated to a given data access method in addition to being difficult to maintain by programmers unfamiliar with the original container design and/or data binding model. Further, a customized data binding implementation results in data binding dependencies on specific data access methods. Such dependencies limit the expandability and/or adaptability of the data binding model to new data access interfaces without significant binding logic changes. For these reasons, existing data binding models and their uniqueness from container to container are undesirable.
Another reason existing data binding techniques are undesirable is because existing data binding models are visual container dependent so that there is no way to accomplish data binding for non-visual objects. Non-visual objects that can benefit from data binding can include, but are not limited to applications that do not have a user interface such as middle-tier business logic objects in a three-tier system. Due to this limitation, existing data binding models and their limited applicability to visual objects are undesirable.
Another reason existing data binding techniques are undesirable is due to the lack of programmer control over application details that occurs once the binding relationship between the data source and the data consumer is established. The lack of control is the result of the container""s internal binding arbiter that buffers and mediates all data access communication and interactivity between every component of the data consumer and every component of the data source. For this reason, existing data binding models are undesirable.
For these and other reasons, there exists an ongoing need for a uniform system of supporting data binding and data access features for visible and non-visible components across multiple applications. A system of this type has heretofore not been known prior to the invention disclosed below.
The present invention solves the above identified and other problems by a container independent data binding system that independently facilitates data binding by way of a binding system object, also known as a binding agent, that is accessible to any visual and/or non-visual component. The binding system is established as an independent Component Object Module (COM) object that is separate from any data consumer or data source client component thereby freeing the client components from the need to individually implement data binding or data access features.
The binding system exposes standard COM object interfaces for use by any client component provided the client component follows established interfaces and protocols. The features provided by the binding system include basic data binding features for an entire data source or for data members of data sources, as well as the transparent data access needed for a data consumer to access the data regardless of the data consumer being a visual and/or non-visual object. Additional binding system features include, but are not limited to and are not required to include, control data verification facilities for client-side control data validation, binding collection for non-data aware objects that can benefit from data binding, data conversion and formatting to control User Interface displays in the context of data binding, and repeater control to facilitate a list view for visual objects, for any object that requires and requests access to these features rather than individually implementing these features without binding system support.
The basic data binding and data access features can be separate from a container due to Binding Collection that allows multiple data consumers to bind to the same data source without each data consumer having specific data awareness or internal data binding implementations. However, Binding Collection is not necessary for objects that have independent knowledge and/or ability to perform their own data binding. The basic data binding and data access features are supported by COM interfaces that include IDataSource and IDataSourceListener. In addition, the binding system is based on an interface arbitration mechanism so that a data bound object can optionally inquire about the data access interfaces that are available when deciding how to access a data source. The data access interfaces allow growth in the types of data access support without requiring changes to the basic data binding mechanisms.
The binding system can provide control data validation to perform field-by-field validation as needed in response to user supplied input. The control data validation features are supported by COM interfaces that include IDataValidate and IDataValidateNotify.
The binding system can provide data repeater control by using data binding in conjunction with a visual object having properties to support a list-style presentation of data that frees the visual object from having to know that a control is being repeated for multiple data items.
The binding system can provide data conversion and/or formatting by way of a DataFormat property to support fine-grained user control over the basic form and presentation of data as the data is being moved between the data source and a data consumer.
These and other container independent data binding system features are disclosed in further detail in the detailed description of the invention below.